Subject: LAN Address Resolution

From: "jim (j.) cobban" <[email-masked]>
Date: Mon, 25 Sep 1995 10:53:00 -0400

As a strong advocate of APPN I take deficiencies in the capabilities of the
architecture very seriously, perhaps too seriously.  I am concerned that the
AIW has not taken the issue of Discovery/LAN Address Resolution very
seriously so far.  Being honest I accept that is as much my fault as
anyone's.  I have been just as willing as the next person to sit back and
wait for IBM to "solve" the problem.

However I do not feel that the proposal which Mark McCorry presented to us at
the last AIW is well designed to satisfy the requirements.  I can appreciate
that IBM has not had a lot of cycles to devote to this issue, but I do not
understand why it was not possible to present the earlier draft document,
which is self-described as being issued on June 19, 1992, in other words even
before the creation of the AIW.  If all that was intended was that the
document form the basis for discussions of what is required, then the sort of
refinement which has held up the release of this document would not be
necessary.  A far cruder proposal would be an adequate starting point for
discussions.

APPN compares poorly compared to other popular protocols in terms of static
configurations which are required just to get the network going.  For
example, it is not possible to construct a "plug-n-play" router for APPN the
way it is for IP or CLNP.  Similarly it is not possible to implement an
end-node which can simply be attached to the media to become operational.

To resolve this it is necessary to first identify the configuration problems
which must be resolved by a solution.  The proposal from IBM states a number
of requirements fairly clearly, but the proposed solution seems to pay
relatively little attention to the requirements.  Instead it appears to go
off trying to solve some other, unstated, set of requirements.

Since my problem set is not identical to that in chapter 2 of the IBM
proposal I will make it explicit:

  1) The requirement is to resolve Subnetwork Point of Attachment (SNPA) 
     addresses for the case where a node is attached to a shared medium which
     supports multicast.  This includes LANs but is NOT limited to LANs.  In
     particular any solution which does not also support X.25, Frame-Relay,
     and ATM is unacceptable to Nortel.
  2) The requirement is to support address resolution within the APPN
     protocol suite, with the specific inclusion of support for dependent LUs
     operating within an APPN network.  That is there is a requirement for a
     node containing dependent LUs to be able to locate a node which provides
     boundary node services.
  3) There is a requirement to be able to determine the SNPAs of all network
     nodes which are attached to the medium.  There are two sub-cases of
     this, where an EN or LEN is looking for a NNS, and where a NN is looking
     for peers.
  4) There is a requirement to be able to determine the SNPA of a particular
     named control point.  This is functionality similar to ARP.
  5) There is a requirement for an EN to be able to optionally derive its
     NETID from its NNS.
  6) There is a requirement for a node to be able to join an existing
     connection network without having the VRN name pre-defined.

There is a reference in the IBM requirements list to "subarea SNA Type 2.1
physical unit".  There is no such animal.  The IBM document also implies
that SNA boundary node services exist only in "Type 4.0/5.0" nodes.
This is not true.  Any APPN node can support boundary node services.  In
particular any node which supports DLUR provides a boundary node.  It is also
possible to provide boundary node services in any case where the node
containing the PLU is logically adjacent to the node containing the SLU.
Logically adjacent means either that the PLU is in the node providing
boundary services, or is connected to that node by non-APPN protocols,
including SNA subarea protocols.  As another nit-pick, the current 3745 is
more accurately described as a type 4.2 node (this terminology was often
used at the time that ACF/x V1R3 was announced).  There has never been any
official use of a decimal point in specifying the architecture level of any
node type except 2.  Furthermore once VTAM and NCP are completely converted
to using APPN protocols there no longer are any PU 4 or PU 5 nodes in the
network, and yet it is still possible for dependent LUs to communicate.

It is useful to consider the experience of other protocols in understanding
the scope of these requirements.  In particular I have examined the following
documents:

 IETF RFC826 - Address Resolution Protocol
 IETF RFC951 - Bootstrap Protocol (BOOTP)
 IETF RFC1497 - Bootstrap Protocol extensions
 ISO 9542 - End System to Intermediate System (ES-IS) protocol for CLNS
 ISO 10030 - End System Routing Info. Exchange Protocol for CONS (X.25)

My requirement number 1 points out several problems with the IBM technical
proposal:

  a) LANs are NOT the only medium over which this capability should be
     available, yet the proposal only provides for transporting MACs and
     SAPs.  Furthermore there is no way that the protocol can be extended to
     support other addressing schemes except by industry agreement to an
     extension to this protocol.
  b) The protocol is only applicable to APPN, and yet media addresses are not
     signalled in a manner which makes them immediately useable by APPN.
     That is the address subvectors must be translated from the format unique
     to this proposal to the format in which they are used within APPN.
  c) Advertisement performs poorly on wide area networks.

To resolve this I propose:

  a) the signalling information should be carried in the form of TG
     descriptor (X'46') subvectors which will permit the information to be
     used by the APPN node without translation.
  b) non-LAN media is supported by the extensions to the TG descriptor
     subfields added for DLUR.
  c) Only the Find/Found subset of this protocol should be used because of
     the poor performance of service advertisement protocols in a WAN.

Although it is unrelated to this specific requirement, it is normal for a TG
descriptor vector to be accompanied by a TG characteristics vector.  It seems
to me that the information in this vector is also important for establishing
a TG with consistent characteristics in both directions, something which is
currently left up to chance.

Carrying the two TG vectors also means that there is enough information
available in the messages to be able to solve several of the other
requirements, in particular to be able to dynamically attach to a connection
network without previously knowing its name.

Since this protocol is specific to SNA in general and to APPN in particular,
it would be preferable if the destination SAP address for this protocol was
X'05', the SNA group SAP, rather than X'DC'.  There are many implementations
which find it inconvenient that the limited SAP address space is continuously
eroded by well-meaning protocol extensions.  In this case there is no
requirement for allocation of a new SAP, and in particular no reason why it
should be an individual SAP, rather than a group SAP.  In either case the
selected SAP must represent ALL of the SNA protocol stacks running on the
target node.  Each individual protocol stack would respond on its own behalf.
For example SAP 04 might respond that it is an APPN network node, while SAP
08 responds that it provides boundary node services.

The terminology CCE may have made some sense during the original discussions,
when it was assumed to have some more general applicability.  Now it is only
one more TLA.  Since the protocol is specific to SNA, if we must have an
acronym for it, I would suggest SNAARE, SNA Address Resolution Element,
pronounced "snare".  This is suggested by the OSI/CONS equivalent function
described in ISO 10030.  It is pronouncable, and I believe easier to
remember.

The current protocol is excessively complicated to achieve even the goals set
out by IBM.  All that we really need is FIND and FOUND.  If somebody wants to
find something they send a FIND, and they get a response back from each
individual entity.  This protocol then becomes so trivial that it is no
longer necessary to distinguish between servers and non-servers.  Everybody
responds on their own behalf.  There is no need for finite state machines,
for example, or timers.

Moreover I would argue that this functionality is invoked so infrequently that
there is little justification for distinguishing between the different kinds
of requested resources at the MAC layer.  After all many very popular
protocols, for example IPX, have merrily used the all stations destination
for years, and nobody has complained.  On the other hand the excessive
filtering in OSI ES-IS has caused a number of architectural and
implementation problems.  I therefore propose that there be ONE
multicast/functional address assigned to the SNAARE capability.  I lost count
trying to keep track of the number of distinct addresses assigned by the
current proposal.  TRN functional addresses are a scarce resource, and should
not be distributed so profligately.

With the SNAARE protocol stripped down to its bare essentials, and thereby
simplified, I believe that it can reasonably be implemented on all SNA nodes,
and therefore should be base functionality in the next generation of the APPN
architecture.